Complex visualizations are graphical user interfaces consisting of graphs, charts, maps and other highly visual presentations of information in a format other than that provided by standard widget sets that include widgets such as text, list, tree, table, etc. They are designed to take advantage of a user's ability to process a large amount of 2- or 3-dimensional information using sight and manipulate it directly with a pointing device.
Over the past decade, as computational speed has increased and high-resolution output devices have become more affordable, an ever increasing number of applications have come to rely on complex visualizations to both convey and support manipulation of complex information. While the expressive and efficient nature of these visualizations has been beneficial to the average user, people with disabilities have been faced with gradual erosion in their ability to interact with applications, and more importantly with their professional peers. When text editors were the prevailing tool used by software practitioners, people with disabilities could be extremely competitive in this industry. With the introduction and broad adoption of visual editors, people with visual disabilities, and to a lesser extent people who have limited use of their hands, can no longer compete as effectively in this field.
The most often used complex visualization applications by software industry practitioners are those considered to be part of a class of applications known as visual editors. Some examples of interfaces for these applications which are relevant to software industry practitioners include flowcharting and UML modeling, workflow specification, and software configuration management. However, the problems associated with these applications are also present in any object drawing application, for example Microsoft® PowerPoint or IBM Lotus® Freelance Graphics.
Accessibility of complex visualizations is not a given. Traditional interface widgets are often accessible without significant additional effort because the underlying GUI toolkit provides keyboard navigability within and between the widgets, and an accessibility API implementation that allows assistive devices to query the widgets and communicate their data in an appropriate manner to disabled users. (In computer programming, a widget (or control) is an interface element that a computer user interacts with, such as a window or a text box. Widgets are sometimes qualified as virtual to distinguish them from their physical counterparts, e.g. virtual buttons that can be clicked with a mouse cursor, vs. physical buttons that can be pressed with a finger. Widgets are often packaged together in widget toolkits. Programmers use widgets to build graphical user interfaces (GUIs).) In contrast, complex visualizations are often constructed from primitive graphical elements that are not inherently accessible. It then becomes necessary for the application developer to understand the underlying accessibility API and essentially duplicate the efforts of the GUI toolkit authors to implement basic accessibility. This effort is similar to creating a custom widget to represent the objects in the visualization.
However, on some platforms the application developer may be fortunate enough to have a 2-d or 3-d graphics toolkit that has already implemented accessibility interfaces. One such toolkit is the Graphics Editing Framework (GEF). Built upon the Standard Widget Toolkit (SWT) based draw2d package, GEF offers an accessible toolkit for developing complex visualizations for the Eclipse framework, or outside Eclipse in standalone SWT applications. GEF has already implemented accessible widgets to represent the elements of complex visualizations. While GEF provides this basic framework for accessibility, it remains the responsibility of the application developer to ensure that each element of the visual display is adequately expressed through the accessibility interface to accommodate the needs of the visually impaired user. More information on GEF can be found here: http://wiki.eclipse.org/index.php/Graphical_Editing_Framework. More information on Eclipse can be found here: http://wiki.eclipse.org/index.php/Main_Page. More information on SWT can be found here: http://www.eclipse.org/swt/.
Users with motor impairment require alternative devices to enable navigation and initiate operations, and keyboard accessibility (along with filter keys and sticky keys) typically satisfies this requirement. The challenges for users that are visually impaired are significantly greater. Complex visualizations rely on the visual comprehension of the user to convey most if not all of the information critical to understanding. When visual comprehension is impossible, all information must be conveyed to the user via screen readers. Screen reader technology is generally limited to interacting with the accessibility programming interface on a given operating system or programming platform. By default, a screen reader can voice only the information provided by the application programmer. Therefore a critical aspect of creating an accessible complex visualization is providing coherent, meaningful text to the accessibility programming interface. With additional scripting, screen readers can be customized for specific applications to improve the efficiency and comprehension of voiced information. However, a well-implemented application accessibility model can reduce or eliminate the need to provide custom scripts for screen reader applications.
Satisfying the requirements of accessibility standards is only the first step toward producing a usable complex visualization. Where sighted users can typically distinguish between the different types of objects in a complex visualization by merely looking, visually impaired users must navigate around the objects and build a mental model of the visualization in their minds. Where sighted users can directly navigate to any desired object simply by moving the cursor and clicking on it with the mouse, visually impaired users must traverse the objects along an ordered path defined by the application programmer until they reach the object of their desire. Where sighted users point and click, visually impaired users must learn and recall a potentially complicated keyboard navigation scheme which may include a large set of keyboard shortcuts to navigate complex visualizations. The inherent inefficiency of the interaction faced by visually impaired users, compounded by the typical complexity of a complex visualization, begs for a concerted effort at improving the usability of such an application.
In view of the foregoing, a need exists to overcome these problems by providing a system and method for improving the navigation of complex visualizations for the visually impaired.